AWS STS エンドポイント利用状況(リージョナル/グローバル)を1日分のCloudTrailログで確認してみた
2024.09.07AWSブログで、グローバル（レガシー）AWS STS エンドポイントを利用するワークロードを、リージョナル AWS STS エンドポイントに移行することで、パフォーマンスと耐障害性を向上させる方法が紹介されました。
今回、グローバル（レガシー）AWS STS エンドポイントの利用状況について、Amazon Athena を利用した CloudTrail ログの解析を行いました。費用抑制のため、解析対象は1日分のログに限定しています。
CloudTrail の設定確認
-
CloudTrail ダッシュボードで、証跡設定と S3 保存が有効であることを確認します。
-
「イベント履歴」ページで「Athena テーブルを作成」機能を利用します。
Athenaクエリを取得
S3
CloudTrail ログ出力先の S3 バケット情報を確認しました。
今回確認を試みた環境、1.5年分、350GB強の証跡ログが存在していました。
Athenaの スキャン課金 (約1.7ドル)を抑制するため、確認期間は1日に限定する事としました。
証跡ログの1オブジェクトからS3 URLを確認、
Athena テーブルの作成
LOCATION 指定に /<アカウントID>/CloudTrail/<リージョン>/yyyy/mm/dd/ を追記、
1日分の証跡ログのみを対象とする SQLを用意しました。
CREATE EXTERNAL TABLE cloudtrail_logs_cm_members_cloudtrail_<日付> (
＜略＞
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://<cloudtrail保存先バケット>/AWSLogs/<アカウントID>/CloudTrail/<リージョン>/<年>/<月>/<日>/'
TBLPROPERTIES ('classification'='cloudtrail');
AWS STS エンドポイントの利用状況分析
AWS STS エンドポイント、リージョナルと、グローバル(レガシー)利用の判別は「clientProvidedHostHeader」で判別可能です。
- リージョナル : sts.<リージョン>.amazonaws.com
- グローバル (レガシー): sts.amazonaws.com
AWS STS エンドポイントの利用状況を分析するために、以下の SQL クエリを実行しました。
SELECT
COUNT(*) AS log_count,
tlsdetails.clientProvidedHostHeader AS host_header,
awsregion AS region,
useragent AS user_agent
FROM
"cloudtrail_0905"
WHERE
eventsource = 'sts.amazonaws.com'
AND tlsdetails.clientProvidedHostHeader LIKE 'sts.%'
GROUP BY
tlsdetails.clientProvidedHostHeader,
awsregion,
useragent
ORDER BY
log_count DESC
今回確認した環境では、リージョナル AWS STS エンドポイントのみの利用が確認されました。
グローバル（レガシー）エンドポイントの利用詳細を確認
グローバル（レガシー）AWS STS エンドポイント sts.amazonaws.com が検出された場合、AWSブログに紹介されている 次の SQL で詳細を確認。
SELECT
eventtime,
recipientaccountid,
eventname,
tlsdetails.clientProvidedHostHeader,
sourceipaddress,
eventid,
useridentity.arn
FROM "cloudtrail_0905"
WHERE
eventsource = 'sts.amazonaws.com' AND
tlsdetails.clientProvidedHostHeader = 'sts.amazonaws.com'
ORDER BY eventtime DESC
可用性の向上や API レイテンシの改善が望ましいワークロードで、グローバル（レガシー）エンドポイントが利用されていた場合、AWSブログ記事で紹介されている一連の対策について検討頂くことをお勧めします。
参考
